home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0799 / 641 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  4.9 KB
  1. Date: Wed, 15 Jun 94 00:12 MET DST
  2. From: chris@buran.fb10.tu-berlin.de (Christian Nieber)
  3. To: gem-list@world.std.com
  4. Subject: RE: Ofir's digest 13.06
  5. Precedence: bulk
  6.  
  7.  
  8. Damien M. Jones,
  9.  
  10. >  - The German developers had the sense to come up with their own
  11. >  - standard long before we did. Give them credit and try to cooperate.
  12. > 
  13. > My point is that they developed keyboard shortcuts which make perfect
  14. > sense to them, but are absolutely baffling to those of us who don't
  15. > speak German.  I find it pretty amazing that you want to "marry" two
  16. > standards that are based on some very different assumptions; at least
  17. > two "standards" are needed, but that seems like a non-standard
  18. > standard.
  19.  
  20. As far as I know ^M and ^U also don't stand for anything in German. I think 
  21. they were just chosen because the keys were still free and whoever invented 
  22. that didn't want to use Shift-Control. Actually the shortcuts we use aren't 
  23. very "german" at all, most of it is still based on the old mac guidelines 
  24. and therefore on english words.
  25.  
  26.  
  27. > ekl@sdf.lonestar.org (Evan K. Langlois)
  28. >
  29. > I've been thinking alot about what's been said about KEYBOARD.SYS or
  30. > SHORTCUT.SYS or whatever, the idea of a global short-cut file, etc.
  31. > I'll have to agree with DMJ.  This file is a good idea, and it makes all
  32. > the arguing over who's "standards" to accept just wasted bandwidth as
  33. > the user can select his or her own "standards".
  34.  
  35. I think standardisation is more important than free definition by the user 
  36. because the majority of users won't bother to redefine shortcuts, and this 
  37. will also be less accepted by programmers if they have to include code. 
  38. Even I am not sure if I will support this in papyrus. Reassigning shortcuts 
  39. is also problematic because in some apps the keyboard is almost full with 
  40. shortcuts, so by redefining one is likely to loose a shortcut for an 
  41. app-specific function - actually it is unpredictable what will happen when 
  42. it is used. That brings me to different idea:
  43.  
  44. The resource suggestion
  45. =======================
  46.  
  47. Many apps read their menu shortcuts from the resource; this also allows 
  48. users to change them with a resource editor. Only this is clumsy for two 
  49. reasons
  50.  
  51.  - users don't want to learn using a RCS, especially since they can easily 
  52. mess something up (hotline nightmare!)
  53.  - when they get a new version of the proggie, they have to do it agin.
  54.  
  55. So one could write a shortcut editor that only allows to change these 
  56. shortcuts and also stores away the changes in a different file. Thus the 
  57. changes can be re-applied to new versions of the RSC by looking for the 
  58. same menu text.
  59. Such a shortcut editor could also be programmed to automatically apply 
  60. rules like "replace all ^Q by ^Z" or "replace ^M in the file menu by 
  61. Shift^S" or similiar.
  62.  
  63. This is perhaps not as powerful as the key definition file, but it will 
  64. work with a lot of existing programs and also deal with the duplicate 
  65. shortcut problem. BTW the application version problem exists in any 
  66. implementation.
  67.  
  68.  
  69.  
  70. > [>CTRL 0 - normal style (reset bold, italic, underline etc.)
  71. > [>CTRL 1 - copy style
  72. > [>CTRL 2 - paste style
  73. > [>CTRL 3 - copy paragraph style
  74. > [>CTRL 4 - paste paragraph style
  75.  
  76. > These seem much too specific, I think.  They appear to be only useful
  77. > for a word processor like, oh, maybe, PAPYRUS?  :)
  78.  
  79. At least the first three and ^B, ^I can be used in drawing programs, 
  80. spreadsheets, database form editors, video title animators, formula editors 
  81. - anything that uses different fonts in one window. On the NeXT even the 
  82. system editor supports different text styles in a document.
  83.  
  84. Evan K. Langlois:
  85. > > Drag-n-Drop was a move, not a copy.  My docs don't mention that.
  86. > > I think it should always be a copy.
  87. > 
  88. > Apple got it wrong (they use move).  Move is a macro for copy-then-delete,
  89. > so the basic op should be copy.  We can laugh at Apple.
  90.  
  91. It can make sense to make this a little inconsistent for convenience. 
  92. Desktops on the ATARI always use copy as the basic operation, while in text 
  93. editing programs move is needed more often than copy because one often 
  94. wants to rearrange words in a sentence or paragraphs in a document. Even 
  95. more so in drawing programs.
  96.  
  97.  
  98. Timothy,
  99.  
  100. > > When the whole text is marked via mark all/CTRL A, a flag is set that the
  101. > > block is non-overwriteable. Delete works (after all there is still Undo),
  102. > > but when the user tries to overwrite it, the block is deselected and the 
  103. typing
  104. > > ends up at the beginning of the document.
  105. > > 
  106. > I had already suggested this as an alternative, but it can get to be
  107. > really damn annoying.  I think it would be best to go back to where the 
  108. > user had last had the cursor or just beep at him until he deselects the 
  109. > block.  Having to move back from page 1 to page 100 that I'm working on 
  110. > every time I accidentally hit Ctrl-A would be far from devistating, but 
  111. > certainly very annoying.
  112.  
  113. Good point. I think I'm going to change that.
  114.  
  115.   Christian (R.O.M. Logicware)
  116.